The Internet of Things (IoT) denotes the interconnection of highly heterogeneous networked entities and networks following a number of communication patterns such as: human-to-human (H2H), human-to-thing (H2T), thing-to-thing (T2T), or thing-to-things (T2Ts). The term IoT was first coined by the Auto-ID center in 1999. Since then, the development of the underlying concepts has ever increased its pace. Nowadays, the IoT presents a strong focus of research with various initiatives working on the (re)design, application, and usage of standard Internet technology in the IoT.
The introduction of IPv6 and web services as fundamental building blocks for IoT applications promises to bring a number of basic advantages including: (i) a homogeneous protocol ecosystem that allows simple integration with Internet hosts; (ii) simplified development of very different appliances; (iii) an unified interface for applications, removing the need for application-level proxies. Such features greatly simplify the deployment of the envisioned scenarios ranging from building automation to production environments to personal area networks, in which very different things such as a temperature sensor, a luminaire, or an RFID tag might interact with each other, with a human carrying a smart phone, or with backend services.
In this setting, a number of IETF working groups are designing new protocols for resource constrained networks of smart things. The 6LoWPAN working group concentrates on the definition of methods and protocols for the efficient transmission and adaptation of IPv6 packets over IEEE 802.15.4 networks. The CoRE working group provides a framework for resource-oriented applications intended to run on constrained IP network (6LoWPAN). One of its main tasks is the definition of a lightweight version of the HTTP protocol, the Constrained Application Protocol (CoAP), that runs over UDP and enables efficient application-level communication for things.
These new protocols are going to enable many different applications including Building Automation Control (BAC), Health monitoring, Smart Energy, etc. In this setting, end devices (such as actuators or sensors) forming a 6LoWPAN/CoAP network will be used for real time monitoring or control of physical parameters and appliances. In the case of BAC, an actuator might be a luminaire and a sensor, a light sensor and the luminaire might access the resources of the light sensor adapting its light settings. Another scenario refers to that one in which a CoAP device (e.g., a client) located in the backend, i.e., outside the 6LoWPAN/CoAP network accesses the resources of a device (e.g., a CoAP server) in the 6LoWPAN/CoAP network over a 6LoWPAN Border Router (6LBR) that interconnects the Internet with the 6LoWPAN/CoAP network. Such an access can be required to obtain specific resources or to push some specific configuration from the backend to the CoAP device in the 6LoWPAN/CoAP network.
Security is a key aspect for the above application areas and use cases. A particular goal of security is the provision of basic security services such as confidentiality, authentication, or freshness between two devices. In the case of using symmetric-key cryptography, this pair of devices shares a common master key that is used during a common handshake for mutual authentication and derivation of a secret session key. This session key is used together with a cipher suite to provide the above security services in the exchange of information between the two devices. A similar handshake can also be performed by means of asymmetric-key cryptography.
In the case of IP protocols, there exist different security protocols including TLS or DTLS. TLS is used to protect protocols at application layer running on top of Transmission Control Protocol (TCP). DTLS is its extension used to protect applications running on UDP. CoAP identifies DTLS as the mandatory approach to protect the exchange of a CoAP communication, while most installed base servers use instead of CoAP, for example, the Hypertext Transfer Protocol (HTTP) which is used in combination with TCP and TLS.
The provision of a secure end-to-end connection is challenging in the above setting. One of the reasons is that the 6LoWPAN Border Router or Proxy (6LBR) should be able to verify whether the exchanged requests between two devices located outside and inside the 6LoWPAN/CoAP network. This happens when, e.g., a CoAP client of a utility company sends a request to a CoAP server (e.g., a smart meter). The 6LBR must be able to verify that requests coming from the client are valid in order to prevent (or limit the effect of), e.g., an energy exhausting attack. Another very interesting situation refers to the existence of legacy devices in the backend, e.g., HTTP devices that should be able to access the information in the end devices in the 6LoWPAN/CoAP network. In this situation, establishing a secure end-to-end connection between, e.g., an HTTP client in the backend and a CoAP server in the 6LoWPAN/CoAP network, remains a challenge due to the diverse key exchange mechanisms being used, i.e., TLS (TCP-based) in the legacy systems, while the constrained 6LOWPAN networks only supports DTLS (UDP-based). This is even more complex because the CoAP devices in the 6LoWPAN/CoAP network do not know where the key establishment requests are coming from.
For certain situations end-to-end connectivity is a must e.g. software updates, network admission, billing, etc. In such situations, an end-to-end handshake is required. On the internet, legacy systems only support HTTP over TCP, and TLS for secure connections. Therefore the specific situation discussed here can be depicted as follows: a HTTP device on the Internet uses HTTP to access resources from a CoAP device directly. The protocol conversion is done by a HTTP/CoAP proxy that is present between them. Goal in this situation is to ensure that the HTTP device can have a secure end-to-end communication using TLS, and the CoAP device can setup a secure end-to-end communication using DTLS.
TCP is a connection-oriented protocol offering a reliable communication. However, UDP is not connection-oriented and does not ensure packet delivery. As stated above, DTLS is an extension of TLS to run over UDP overcoming the limitations of UDP. In both cases, the initial handshake of TLS and DTLS comprises the exchange of 4 set of messages between the client and the server. Below we discuss the minimum handshake. Note that each step refers to the sending of a number of messages from a first device (e.g., client) to a second device (e.g., server).
Step 1 (from Client to Server): Client Hello
Step 2 (from Server to Client): Server Hello; ServerHelloDone
Step 3 (from Client to Server): ClientKeyExchange; ChangeCipherSpec; Finished
Step 4 (from Server to Client): ChangeCipherSpec, Finished
Although DTLS is based on TLS and the messages above remain the same, there are minor differences which make the protocols not interoperable with each other. Some of the differences are:
A cookie mechanism can be used in DTLS to verify the existence of a client initiating the requests. In TLS, such a cookie mechanism is not required because the TCP three-way handshake determines the existence of the client.
DTLS incorporates additional fields to provide the needed reliability for running DTLS over UDP. In TLS, the underlying TCP layer provides the needed reliability so that those fields are not required.
DTLS relies on a retransmission mechanism during the initial handshake to ensure that the messages sent by a first device are received by the second device. TLS does not require such an approach since reliable transmission is ensured by TCP.